Group Policy

Identity

4 sections
18 source tickets

Last synthesized: 2026-02-13 02:52 | Model: gpt-5-mini
Table of Contents

1. Incorrect Okta dynamic group membership due to malformed attribute values

2 tickets

2. Missing or incorrect group creation, assignment and directory synchronization

9 tickets

3. Azure AD / Microsoft Teams policy enforcement and group-based controls

4 tickets

4. Corporate Group Policy enforced settings preventing per-user changes

3 tickets

1. Incorrect Okta dynamic group membership due to malformed attribute values
80% confidence
Problem Pattern

Okta dynamic group rules produced incorrect enrollments because membership criteria contained combined or incorrect attribute values (cost-center entries, job-title mappings) causing unintended users to be added to role-based groups and downstream automations.

Solution

Membership errors were resolved by reconciling and correcting the dynamic rule criteria: duplicated/combined cost-center text was removed and the correct discrete cost-center entries were applied while preserving the existing hire-date filter. After the rule was cleaned up and validated the dynamic group membership and the automation dependent on it reflected the intended members.

Source Tickets (2)
2. Missing or incorrect group creation, assignment and directory synchronization
90% confidence
Problem Pattern

Group objects or memberships were incorrect or inconsistent: expected groups were missing, users were in the wrong groups, or automated HR-sourced groups contained inappropriate members (for example, 'leitende Angestellte' in works-council groups). Symptoms included lost or incorrect privileges, inability of group owners to edit or self-manage provisioned groups, and delays or local client state preventing updated privileges from taking effect. Triggers included identity attribute changes (email, profile), provisioning source mismatches, and directory synchronization delays across systems (Workday, Okta, Salesforce, EPOS/Care, Windows client assignments).

Solution

Issues were resolved by creating missing group objects, performing targeted membership updates and mappings, and allowing directory synchronization or client restart to propagate state. Actions that restored expected group presence and privileges included: adding the missing 'Okta-MFA' Windows 11 group and manually assigning Win11 groups to affected users; updating an individual's Okta group membership to match a Salesforce profile change; updating a user email in EPOS and Care, removing the user from the EPOS group and adding them to the myCampus group while reassigning the appropriate Care group; adding support staff to the Kentix admin group and allowing directory sync to propagate; and confirming group membership then restarting the client where pending local state blocked admin rights. For an automated Workday provisioning issue that included 'leitende Angestellte' in works-council groups and prevented group owner self-management, the record was linked to a related Workday provisioning ticket and stakeholders were advised to schedule follow-up with the Workday contact; no technical fix was recorded in that ticket.

3. Azure AD / Microsoft Teams policy enforcement and group-based controls
70% confidence
Problem Pattern

Policy enforcement via Azure AD groups and third-party policy engines caused unexpected group behavior and classification issues: Teams groups had incorrect classifications, meeting-creation accounts bypassed Teams AI-notetaker blocks, and AvePoint 'Policies for Office 365' intermittently removed members from Course Feed groups.

Solution

Teams classifications were updated in the Teams Admin Center to reflect the new classification taxonomy. Where meeting-scheduling accounts caused AI notetakers to bypass a blocking policy, the affected account was added to the Azure AD group controlling the Teams policy so the block applied. Investigations into Course Feed removals attributed the behavior to AvePoint 'Policies for Office 365' enforcing membership constraints (removals were initiated by AvePoint and tied to who performed the add). Notifications originating from internal configuration changes were validated as legitimate.

4. Corporate Group Policy enforced settings preventing per-user changes
95% confidence
Problem Pattern

End users reported Windows settings that were locked, reverted, or required administrative privileges to change — examples included power behaviors (lid-close action causing hibernation), power-saving modes, and desktop background. Attempts to persist local changes failed or were reset shortly after because organization-wide Group Policy applied non-granular, enforced values.

Solution

Support investigated and confirmed the reported settings were controlled by organization-wide Group Policy (GPO/AD) that enforced binary, non-granular values for items such as power options (lid-close action/hibernation), power-saving modes, desktop background, and accessibility settings. The policies were required by corporate security and could not be configured on a per-user basis; local changes could not be made persistent. Temporary administrative changes were possible but were overwritten during Group Policy refreshes (typically within minutes). The investigation and limitations were documented and communicated to affected users, and the request was forwarded to the security/policy owners for consideration of any policy changes.

Back to Summaries
An unhandled error has occurred. Reload X